What! After all these endless debates Magento 2 might move from Less to Sass?!
TL;DR: Yes.
History
One of the original reasons for selecting Less over Sass was at the time there was no PHP implementation of a Sass preprocessor. There was also no clear winner between Less and Sass in the market. While this may spark a debate, from all the feedback we have received Sass is pretty clearly winning.
How Different is Less and Sass?
From a technical perspective, not a lot really. There is a lot of commonality between the power of both preprocessing languages. So frankly if you have spent lots of effort learning Less, it won’t take you long to move to Sass.
The decision to move is not a question of expressive power, it is a question of market mindshare. There is extensive feedback from the community that Sass is the better way to go.
So What is the Work?
What is the work required to do the move? There are several aspects:
- We need to port the Magento UI Library, blank and Luma themes, admin theme, and Less files in core modules from Less to Sass. The core library is the “real” work here.
- We need to give extension developers enough notice so that if they are using Less they have time to migrate over to Sass. We want to make the new Sass files available well in advance so porting can be more easily scheduled. We also want sufficient time for feedback if any improvements are needed.
- We want to give the frontend developer community enough time to think through issues to make sure we get the new files “right” (or as right as possible), before they become official. I am sure frontend developers always agree, so I am not expecting any challenges here… ummm.
It is worth remembering that there are distinct communities interested in these files:
- Magento development has to maintain and build them into the core product.
- Solution Partners need to build rich, seamless solutions for customers, worrying about performance and maintenance.
- Extension Developers need to build extensions that are easy for Solution Partners to work with.
- Theme Developers need to be able to change the theme of a site with minimal effort.
Oh, and to be clear, this work is not about changing the look and feel. This is not a UX redesign. It is achieving the same look and feel using Sass instead of Less.
How is this Going to Happen?
SNOW.DOG have already ported the blank theme from Less to Sass. They also did some great work with Gulp integration with Magento 2. So Magento has asked SNOW.DOG to lead a community effort around the Sass port, which SNOW.DOG has graciously agreed to do.
The idea is to develop the new Sass files as a community project, get feedback from multiple interested parties, and then merge into Magento 2 at a future date. The benefits are:
- Get real world frontend developers working through issues and complexities in the open.
- Accelerate development – the core Magento team have many other obligations as well. This is a way to get the move done sooner.
- Tap into the great talent pool and real-world experience in the community, while Magento remains involved for consistency.
- See how well larger scale community-led projects work in practice.
Are the Less Files Going Away?
Maybe one day, but they will probably sit around in the product (or in a separate module) without being actively maintained. As above, Magento can still support Less, so all the existing files will continue to work, it just won’t be the recommended default. At the end of the day, the output is CSS.
What is the Architectural Changes Behind This?
This is still to be decided, but the current plan is around simplification. Sass might be out of date next year given the rate of change in frontend development. So what is stable? The current plan is to base the solution around:
- Files on disk – with modules and themes being able to override existing files. This is how a theme can customize. No other magic, just file replacement using the standard Magento file fallback strategies.
- External tools can convert source files to CSS. We need to think about what to build into the product, but it must be possible to run external tools (like Grunt and Gulp) in the build process.
- Magento tools for merging CSS files (maybe). Basically we want it simple for small sites to get reasonable performance. So we are considering a default mode where modules can add new CSS files if they want them, and Magento will merge (and minify) them into a single file with a single setting in the Admin panel. Expert frontend developers may turn this off, and do all file merging by hand for fine tuning.
Timeline
Assuming the project is successful and consensus is reached of the best way to leverage Sass, the objective is to get the final files merged in by the end of 2016. This would include an extended period of time for extension developers to be able to move any code they have (if they just used raw CSS there is nothing for them to do). Note that this is not a guarantee, but it is a goal. The more important aspect is to get the Sass files right, where Solution Partners, Extension Developers, and Magento are all happy with the new files. This is more important than a date.
OMG – The Sky will Fall! Can’t Magento Make up their Minds?
I would rather fix problems. We don’t want Magento to be unstable, but the consistent feedback is this one is worth changing. And if the frontend community comes back and says “don’t change anything, Less is great after all” then we won’t! We will let those in the community who care most get involved in setting the future direction here.
And I think the breadth of the community involvement is the greatest protection that the new Sass files, when completed, will be a step forwards.
And the move is really to abstract the Magento support for CSS preprocessors. We want to have less built in dependence on a particular language, and instead make it easier for a project to select their own. The core files are really a great place that Solution Partners, Extension Developers, and Theme Developers can all meet.
I am also not expecting significant impact on extension developers as: if they use their own native CSS files there is no impact; if they depend on our Magento UI Library Less files, they can continue to generate CSS from them (although this is unlikely to be widespread due to a current defect making it hard for modules to use our Less libraries). The biggest impact appears to be on solution partners (the primary source of the change request, including using more standard frontend developer tools) and theme developers. But please leave a comment if you have data indicating otherwise!
Conclusions
Thank you to Kuba and SNOW.DOG for offering to oversee this project. SNOW.DOG has already looped in a number of people from different Magento development shops to get the breadth of perspectives that come from such a diverse community. Staff from Magento are also involved, but this is going to be a true community project. Hopefully, this will serve as a great template for further work in the future, drawing upon community expertise to get a product built that best addresses the community’s needs.
Alan Kent's Blog 
Thank’s, Alan! 😀
Yay! Looking forward to it!
You should support and maintain both. Less has a lot of users too. Or the community should maintain less.
Thanks for the writeup and for explaining more of the thought process behind moving from LESS to Sass. I’m excited about the move.
I think that once the switch has been made to Sass, Magento should stick with Sass and not update the LESS files, as maintaining two different sets of stylesheets would be cumbersome.
A few things I’d love to see improved as the migration to Sass is being done:
1. The Magento UI Library is a great step in the right direction. However the UI Library only references the mixins necessary to implement the styles. Instead, it should list both the mixins as well as as CSS classes that can be used by either the Blank or Luma theme to take advantage of those pre-built styles. It would be great to see the UI Library become as useful as http://getbootstrap.com/components/
Also, There should be an officially hosted location for the UI Library (see https://github.com/magento/devdocs/issues/526) rather than having to access it via a link like http://magento2-demo.nexcess.net/pub/static/frontend/Magento/blank/en_US/css/docs/index.html
2. Magento should create guidelines for extension developers that have a strong recommendation for those developers to integrate with the UI Library. Most of the M2 extensions I’ve seen up to this point *don’t* use the UI Library and the LESS variables in native M2, which is a shame.
1. This leads to have 1 file for whole store (b/c in other case every module/view will contain whole Magento UI lib #ohgodwhy) and even when you don’t want to use Magento UI, you have tons of selectors loaded by default.
Idea of UI lib containing only mixins and/or sass placeholders IMO is the right way that we should follow.
For sure Magento UI needs good „global” docs, but as you probably know Magento UI depends on theme variables, so global version can’t exist, b/c docs generated from „blank” or „luma” will looks different out of the box. AFAIK standalone compiling will fail, b/c of undefined variables.
2. Big thumbsup – this should be included somehow on marketplace tests level – “if you write bad styles code, your extension will not be accepted to marketplace”
A decoupled frontend would be the best solution imho.
I honestly don’t understand this need to choose the tools that a frontend dev should use.
With magento 1.x i’ve used grunt, compass, gulp, sass, less, babel, i was free. If tomorrow a new css prepocessor comes out I’m sure that i can use it with magento 1.9, but not with 2.x.
Magento 2 already has support for developers to build their own processors, but ultimately most people will just use what M2 natively provides. Which is why the push to switch to Sass has been so significant, as that pre-processor has emerged as the leader and people want to use Sass with M2 without the trouble of implementing their own processor or default styles.
I think a decoupled frontend is nice is theory, but a system like Magento has to pick a technology to embed as their native CSS pre-processor. Trying to be truly decoupled from any CSS pre-processor would mean that they would need to ship style file for multiple pre-processors, invent their own, or ship native CSS. None of which are great options.
Yes, in theory you can use your own pre-processor, but it isn’t so easy.
igloczek made a really good work with frontools, but I see it as a good workaround, decoupling the css compilation from Magento. It’s not so easy to replace the php less preprocessor integrated in Magento, I didn’t see anyone doing that. At least it’s not as easy as setting up a new gulp task.
According to you, if Magento had to pick a native CSS pre-processor instead of shipping simple CSS (what’s wrong with css?) why it didn’t picked an ‘official’ JS pre-preprocessor like Typescript or Babel instead of shipping javascript?
I’m not saying that X is better than Y and i don’t want to start a religion war, in the end a browser doesn’t care if the css comes from sass or less, in the same way it doesn’t care about Babel or Typescript.
I work on Magento everyday and i have to say that the frontend workflow in really slow, tedious and full of nonsense. Following the official documentation it takes more than a minute to see a change in a page served from a vagrant box running on a quad-core i5 with 16GB and a ssd. It isn’t the ideal workflow.
Magento 2 seems a little bit overcomplex and heavy in areas where there is no need, it seems a little against KISS and DRY principles, but that’s my opinion.
> what’s wrong with css?
Did you ever try to maintain big project without partials, variables and functions?
It’s like you should stop writing PHP and swap to pure HTML, b/c at the end output is HTML.
I’d heavily recommend writing advices or improve codebase, rather than just yeling about what is wrong with M2 🙂
Peace
First of all, a big thank you for your frontools!
Obviously you’re right, css pre-processors are crucial tools. What I try to point out is that encapsulating them inside Magento wasn’t the best thing to do, according to me, because this add complexity to the system without achieving a better functionality than an external tool (e.g. frontools), also affecting performance.
RWD from 1.9 is a good example, it has sass but it’s not linked with the core.
I assure you that i’m contributing where i can on github, but i’m still a newbie in Magento, i only tried to expose my idea, maybe someone read it and comes up with a better solution ;D
Have a good day
Going back to CSS files in repositories is huge step backward and is agains maintainable code good practices.
If someone nowadays can’t handle styles pre-processing, should re-think his/her developer carrier… It’s not ~2010 anymore.
@Lorenzo – I don’t think there is any argument that Magento needs to use a CSS pre-compiler. And while mid to large size merchants will have no problem hiring a developer that is capable of handling setting up a Gulp/Grunt/etc workflow to compile CSS, many small merchants won’t. And therefore Magento ought to ship with a solution for compiling CSS from within the application. That is part of what motivated Magento to pick LESS, as it had a PHP compiler.
If Magento didn’t ship with a builtin CSS compilation process, you would alienate a lot of small merchants, something Alan Storm has already brought up concerns about from the aspect of just installing Magento 2: https://github.com/magento/magento2/issues/4020
Yes – we MUST support out of box experience while making it better for solution partners. That does add complexity, but it is not optional.
Alan,
Yes Sass is the current front runner, and yes there might be the new hotness coming in the future (PostCss as an example), but it’s definitely worth swapping out Less for Sass now, as that’s the current winner of the css preprocessor wars. It might not even be as necessary to do all that work if there was a clear example of how to use Sass. The best source of how to do this is here: https://github.com/magento/magento2-samples/tree/master/module-sample-scss , except it doesn’t show how to include the underlying Sass module (probably with composer), and there’s no clear information regarding whether or not we can do this on top of blank or Luma themes (if we implement Sass will both Less and Sass be transpiled?). Next, how would the front-end tooling work? Etc….
So it would be really helpful to get an official Magento explanation of using Sass now, while the community effort to include Sass (or make the framework flexible enough to use whatever in the future) is underway. Is that possible? I was hesitant to use Snowdog’s theme as it would need to be updated after every M2 release, plus it’s not officially sanctioned.
Any feedback?
Thanks for the continues awesomeness!
There is a section in devdocs on using sass using built in tools. But tools like gulp seem better (eg frontools from snow dog). Goal is to get community agreement on new sass files before we make them official. So reviews of what snow dog has already done is useful
Alan,
Thank you for the reply. Yes, there is this section: http://devdocs.magento.com/guides/v2.0/frontend-dev-guide/css-topics/custom_preprocess.html , but it doesn’t show an example of including the actual sass/scss php module (I can appreciate that it’s better to let individuals use their own choice, but it would be nice for thoroughness).
Thank you for the comment on front-end tooling as well. Really looking forward to Snow Dog’s work.
Thanks!
Sounds good using SASS.
Would like you to consider how we may want to create a theme from scratch rather than using the Blank theme. Majority of big enterprise sites we work on do not look anything like Blank theme so it is all massively redundant (as well as the ui library not being appropriate for what we want to achieve).
We would for example want to create our theme from scratch and follow another structure like https://smacss.com (which is what we have done with M1 many times).
Look forward to seeing how it works out.
There is a community project (led by SNOW.DOG) investigating redoing the base Sass files. Feel free to reach out to them if you want to contribute.
We purposely separated HTML, JS, and CSS in M2 to make it easier to replace all or one without the others. We were also wondering about improving the “class” declarations in the HTML to make it easier to simplify the CSS.
My question to you would be around do you need to replace “blank” or just the CSS etc files in it. Something to consider. But there is nothing built in special about “blank”. You can certainly develop new themes that do not inherit from “blank” at all. There are no technical reasons not to do so. Blank is provided as a useful starting point. If not useful, there is not requirement to do so.
Using SASS would be a positive step forward in my option.
I’d like the Magento team to consider those of us who want to build themes from scratch rather than relying on “Blank” theme (simple because Blank does not resemble anything like what we are trying to achieve with our recent enterprise project in M2). For example on M1 we would use SASS and follow the SMACSS structure completely overriding any styling or images or libraries from Magento.
I also saw this project at the Meet Magento in Germany. Looks really awesome and promising! But there is one question left: What was the reason for the first decision to use LESS anyway? As far as I know there were some feedback rounds about Less/Sass on Github, weren’t they?
There is history. At the time Less was at least as equally popular as Sass, but more importantly there was a php implementation of Less and not of Sass.
Hi Alan, besides adding Sass preprocessor into current architecture and rewriting *.less to *.sass did Magento consider embedding some existing asset management solution instead of adding features to the one written from scratch?
I allude to Assetic library https://github.com/kriswallsmith/assetic#filters which is the de facto standard in Symfony ecosystem, is pretty flexible and feature rich.
In particular, it provides LESS (both PHP and NodeJS-based), SASS preprocessing, CSS/JS minification and merging out-of-the-box. More than that, it allows to create any combination of such operations pretty easily: for instance, if you use core theme based on LESS you can just dump it to CSS and write your additional styles with SASS.
Of course, there are quite a lot Magento-specific code which Assetic library is not aware of, like theme inheritance, materialization rules, but it can be reused with Assetic just like it is used currenty with just some Lessphp lib.
So, my proposal is to replace asset management related stuff with Assetic implementations as there is no need to reinvent the wheel if there is one which rolls good already. This does not seem to be a breaking change, existing interfaces may be reused and probably some more added, just a change of what’s going on under the hood.
We are looking at making M2 more friendly with external tools to allow more flexibility here. There is a lot of work going on with NodeJS that we just want to use, rather than build in. Working through some challenges with “default” mode at the moment.
(Sorry – hit send too soon.) Thanks for the link – we will have a look at that as well.
Have you guys heard of https://github.com/brauliobo/less2sass gem. Might help speed things up a bit!
Hi, I was wondering how you all manage the extensions that come with LESS if you are using SASS
Thanks